<
programming> The tendency of software that has not been used
in a while to fail; such failure may be semi-humorously
ascribed to
bit rot. More commonly, "software
rot" strikes
when a program's assumptions become out of date. If the
design was insufficiently
robust, this may cause it to fail
in mysterious ways.
For example, owing to shortsightedness in the design of some
COBOL programs, many would have succumbed to software
rot when
their 2-digit year counters wrapped around at the beginning of
the year 2000. A related incident made the news in 1990, when
a gentleman born in 1889 applied for a driver's licence
renewal in Raleigh, North Carolina. The system refused to
issue the card, probably because with 2-digit years the ages
101 and
1 cannot be distinguished.
Historical note: Software
rot in an even funnier sense than
the mythical one was a real problem on early research
computers (e.g. the
R1; see
grind crank). If a program
that depended on a peculiar instruction hadn't been run in
quite a while, the user might discover that the
opcodes no
longer did the same things they once did. ("Hey, so-and-so
needs an instruction to do such-and-such. We can
snarf this
opcode, right? No one uses it.")
Another classic example of this sprang from the time an
MIT
hacker found a simple way to double the speed of the
unconditional jump instruction on a
PDP-6, so he patched the
hardware. Unfortunately, this broke some fragile timing
software in a music-playing program, throwing its output out
of tune. This was fixed by adding a defensive initialisation
routine to compare the speed of a timing loop with the
real-time clock; in other words, it figured out how fast the
PDP-6 was that day, and corrected appropriately.
[
Jargon File]
(2002-02-22)